The IoT Architect's Guide to Attainable Security and Privacy by Damilare D. Fagbemi;David M Wheeler;JC Wheeler;

Author:Damilare D. Fagbemi;David M Wheeler;JC Wheeler; [Неизв.]
Language: eng
Format: epub
Publisher: CRC Press (Unlimited)
Published: 2020-01-25T21:00:00+00:00

In the Dalit Device Software Updates view, the system administrator publishes signed containers to the Container Registry. The container registry is simply a repository of update files stored as containers. Afterwards, the system administrator uses a web application (also hosted via AWS S3), with the aid of a Lambda function, in order to publish a new desired state to the Device Shadow compute service. The Lambda function is accessible to the web app via an API (or URL) it exposes through the Amazon API Gateway™ compute service. The API gateway is simply a service that allows for easy creation and manipulation of REST APIs. The Amazon API Gateway can be used to create an API that is simultaneously connected to disparate cloud-hosted data sources, presenting a simplified interface for a client accessing that API. In our current example case, the REST API is connected to the functions exposed by the “set desired device state” serverless function.

Take a moment to consider what was described in the last paragraph and compare it with the approaches described in “Device Maintenance, Updates, and Monitoring” in Section 6.4.2. Might there be a smarter way to architect this update system for Dalit? Take a moment to analyze. Yes, you’ve probably found it. It is possible and perhaps better to architect a system in which device updates are tagged with a device ID or device group ID, such that the system can automatically associate an update with the device or devices. This will eliminate our example step in which an administrator manually updates the device shadow service with a configuration that directs a device to pull down an update from the container registry. Our challenge to you: Go architect it!

Let us not forget that the system administrator’s access to the device shadow service and the container registry must be authenticated and authorized via the identity service. Figure 6.6 depicts the admin’s authentication to the device shadow service via Cognito. But although Figure 6.6 does not include the admin’s authentication to the container registry, that is just as important. How would you accomplish such authentication? There are a few options—utilizing a built-in authentication service such as AWS Cognito, or allowing Secure Shell (SSH)–based direct access to the network and machine(s) that host the container registry. Both approaches make use of the identity service. Also, in either case, the principle of least privilege must be enforced to ensure that only the administrators who are designated to update containers in the container registry have those access permissions.

The Device Shadow service is popularized by AWS but can be implemented by any cloud provider or in a private cloud. It holds records of the last known state and desired future state of edge devices, even when the device is offline. The Device Shadow service publishes new desired states to a corresponding topic on the message broker, where they are be picked up by edge devices that are subscribed to the same topic. To update the edge devices, the future state contains information about the URL of the elastic container registry where the updates reside.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.